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ABSTRACT 

IBM  Business  Integration  Modeler  Advanced  Edition  allows  Future  Logistics  Information 
Environment  task  members  to  map  business  processes  around  existing  systems  and  has  been 
used  to  map  processes  surrounding  the  Movement  Management  System.  During  this 
mapping  process  a  number  of  lessons  were  identified  and  to  ensure  that  these  are  captured 
this  document  has  been  developed  with  a  series  of  best  practices  and  recommendation  so  that 
these  lessons  are  learnt  and  future  FLIE  task  members  do  not  suffer  the  same  issues.  Although 
many  of  the  recommendation  and  practices  are  tailored  to  the  FLIE  task  requirements  other 
projects  will  also  benefit. 
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Executive  Summary 

During  the  mapping  of  the  JP2030  Movement  Management  System  (MMS)  business 
processes  using  the  IBM  Business  Integration  Modeler  Advanced  edition  a  number  of 
problems  were  identified  and  solutions  found.  To  ensure  that  other  Future  Logistics 
Information  Environment  (FLIE)  task  members  do  not  encounter  these  problems  again 
a  series  of  recommendations  and  practices  have  been  captured  herein. 

These  recommendations  and  practices  should  be  followed  by  FLIE  task  members  as 
they  ensure  that  models  produced  are  consistent  and  relate  to  one  another.  Other 
projects  will  also  benefit  as  a  number  of  workarounds  are  documented  herein  that 
overcome  some  processing  requirements  that  require  unique  process  structures. 

This  document  will  be  updated  over  time  so  please  refer  to  the  DSTO  FLIE  Sharepoint 
task  site  (http:/ / c2d-teams.dsto.defence.gov.au/ task/ 04-072/)  for  an  updated  version 
of  this  document.  If  you  have  additional  recommendations,  best  practices  or  lessons  in 
the  use  of  Business  Modeler  please  contact  Egon  Kuster  (FLIE  Task  Manager, 
Command  and  Control  Division,  egon.kuster@dsto.defence.gov.au). 
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Acronyms 


Acronym 

Description 

ADO 

Australian  Defence  Organisation 

BPEL 

Business  Process  Execution  Language 

CVS 

Concurrent  Versions  System 

FTP 

File  Transfer  Protocol 

FLIE 

Future  Logistics  Information  Environment 

MMS 

Movement  Management  System 
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Glossary 


Term 

Description 

Annotation 

Element  used  to  describe  other  elements. 

Artifact 

A  component  within  a  project,  such  as  a  resource  or  a 
business  item. 

Broadcaster 

An  element  used  in  conjunction  with  a  Receiver, 
linked  together  with  a  Notification.  Designed  to 
broadcast  a  signal  to  one  or  more  receivers,  where  the 
process  resumes. 

Business  Item 

A  physical  item  used  in  a  business  process  (e.g.  an 
requisition  order). 

Business  Modeler 

IBM  application  used  to  model  business  processes. 

Business  Process 

Process  undertaken  in  a  business  environment. 

Concurrent  Processing 

Multiple  tasks  executing  at  the  same  time. 

Connection 

Used  to  connect  tasks  together. 

Element 

An  item  in  a  process  model. 

End  node 

Signifies  where  processing  stops. 

Expression 

Used  to  define  rules,  constraints  and  preconditions. 
Expressions  are  conditions  or  mathematical  functions 
that  can  be  evaluated. 

Expression  Builder 

The  tool  used  in  Business  Modeler  to  create  an 
expression. 

FLIECVS  Repository 

The  FLIE  tasks  CVS  repository.  This  is  where  all 
Business  Modeler  workspaces  are  stored  for  the  FLIE 
task. 

Flowchart 

A  diagrammatical  representation  of  information, 
processing  or  data  flow. 

General  practice 

A  general  practice  that  does  not  relate  to  the  FLIE 
environment  by  may  be  applied  to  most  projects. 

Global  Task 

A  task  that  is  global  to  the  project.  Global  task  can  be 
reused  in  multiple  process  diagrams. 

Join 

Element  used  to  join  two  concurrent  connections  into 
a  single  output.  Joins  wait  for  all  inputs  before 
executing  and  merging  the  input  data. 

Local  Process 

A  process  that  aggregates  detailed  subtasks.  Used  for 
easier  visibility  of  large  processes. 

Local  Task 

A  task  which  is  only  visible  within  the  process  model 
it  was  created  in. 

Merge 

Element  used  to  merge  two  connections  into  a  single 
output.  A  merge  executes  as  soon  as  the  first  input 
arrives. 

Notification 

Element  used  in  conjunction  with  a  Broadcaster  and 
Receiver.  The  Notification  is  the  link  between  these 
two  elements  and  contains  details  about  the  content  of 
the  notification. 

Observer 

Element  that  stops  process  flow  until  a  defined 
condition  is  met. 

Process 

A  sequence  followed  to  complete  an  action  or  meet  a 
goal. 
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Process  Model 

A  diagrammatical  view  of  a  business  process. 

Project 

Where  multiple  related  Processes,  Elements  and 
Artifacts  co-exist. 

Project  Tree 

Displays  all  components  in  the  current  workspace, 
such  as  Resources,  Organisations  etc. 

Project  Tree  Filter 

Filters  out  certain  components  of  a  project  in  the 
project  tree,  such  as  Resources,  Organisations  etc. 

Receiver 

Element  used  in  conjunction  with  a  Broadcaster, 
linked  with  a  Notification.  Receives  a  Notification  sent 
from  a  Broadcaster  and  is  where  the  process  resumes. 

Repository 

Element  that  holds  multiple  business  items  that  a 
process  accesses  at  any  given  time.  Can  be  local  or 
global. 

Resource 

What  tasks  use  to  operate. 

Sequence  of  Execution 

The  execution  or  flow  of  a  process  model. 

Start  node 

Signifies  where  a  process  is  to  start. 

Stop  node 

Signifies  where  a  process  is  to  stop. 

Task 

Element  that  represents  an  activity  (e.g.  'Process 
order'). 

Task  specific  practice 

FLIE  related  practice  to  help  administer  and 
understand  process  models  developed  for  FLIE. 

Workspace 

The  location  that  project  exists  in.  A  workspace  can 
have  multiple  projects. 

Process  Simulation 

A  simulation  of  a  process  model.  Used  to  test  out  a 
process  and  verify  that  it  is  correct  or  produce  metrics. 

Simulation  Snapshot 

An  instance  of  the  process  model  and  its  artifacts  at  a 
point  in  time  during  a  simulation  execution. 

Attribute 

Field  in  an  Artifact  that  describes  itself,  such  as  a 
business  item. 
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1.  Introduction 


This  document  outlines  the  best  practices,  in  the  form  of  recommendations,  for  using 
IBM  WebSphere  Business  Integration  Modeler  Advanced  Edition  (Business  Modeler) 
software,  version  5.1. 1.2.  Members  of  the  DSTO  Future  Logistics  Information 
Environment  (FLIE)  task  developed  these  best  practices  and  recommendations  during 
the  analysis  of  the  Australian  Defence  Organisation  (ADO)  Movement  Management 
System  (MMS)  logistic  systems.  While  primarily  written  to  support  existing  FLIE  task 
members,  this  document  is  also  designed  to  help  new  users  of  Business  Modeler.  It  is 
expected  that  FLIE  members  will  adhere  to  these  recommendations  when  using 
Business  Modeler.  This  document  concentrates  only  on  using  the  Business  Modeler  tool, 
if  you  are  interested  in  the  products  produced  or  the  analysis  process  applied  then  refer 
to  the  "Future  Logistics  Information  Environment:  Movement  Planning  Process" 
document  [1]. 

Business  Modeler  is  a  complex  tool  that  allows  users  to  analyse  business  processes 
within  the  business  environment.  While  still  making  use  of  basic  flowchart  structures 
such  as  decisions,  processes  and  repositories.  Business  Modeler  adds  functionality  by 
introducing  elements  such  as  receivers,  broadcasters,  joins,  merges,  observers  and 
others.  These  new  concepts  allow  for  advanced  business  process  modeling. 

Business  process  models  can  be  viewed  at  two  levels  within  Business  Modeler,  either  at 
the  general  business  level  or  the  more  advanced  technical  level.  At  the  advanced  level 
users  can  start  to  edit  more  complex  attributes  of  the  business  process  including 
assigning  expressions  to  decisions  and  observers,  simulating  processes  to  calculate  net 
costs,  timing,  and  so  on.  Splitting  the  tool  into  two  views  allows  for  a  basic  business 
process  to  be  captured  at  the  general  basic  level  and  then  later  assign  more  complexity 
and  details  allowing  for  the  process  to  be  executed,  simulated  and  inserted  into  an 
operational  environment.  Therefore  this  tool  helps  bridge  the  gap  between  simply 
documenting  the  process  and  actually  executing  processes  within  the  enterprise  system. 
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2.  Best  Practices 


The  best  practices  and  recommendations  presented  below  are  divided  into  those  specific 
to  the  FLIE  task  (section  2.1)  and  those  likely  to  be  generally  useful  to  all  Business 
Modeler  users  (section  2.2). 

2.1  Task  Specific  Practices 

The  practices  described  herein  are  specific  procedures  to  be  undertaken  in  order  to 
properly  administer  a  Business  Modeler  project  in  the  FLIE  team  environment. 
However,  these  practices  are  most  likely  applicable  to  other  team  environments. 

2.1.1  Study  Workshop  Documentation  and  Examples 

There  is  a  "Quickstart  Guide"  [2]  which  provides  a  basic  overview  of  Business  Modeler's 
capabilities.  The  examples  from  the  tutorials[3]  and  "Quickstart  Guide"  should  take  a 
maximum  of  one  day  to  read  and  complete.  These  tutorials  can  also  be  found  in  the 
Business  Modeler  help  by  accessing  the  "Information  Center"  and  selecting  'Getting 
Started  ->  Tutorials' (see  Figure  1). 


Contents 

Modeler  Advanced  Edition  <Ja  c£> 

Modeler  Advanced  Edition 

0  Q3  Viewing  information  with  the  help  system 

Tutorial:  Creating  a  simple  process  model 

ll  Information  roadmap 

0  03  Product  overview 

A  process  model  is  a  representation  of  a  real-time  business  process  and  is  composed  of  the  individual  steps  or 

activities  that  make  up  the  process.  It  can  include  the  conditions  that  dictate  when  those  activities  occur  and  th< 

0  03  Tutorials 

resources  required  for  their  performance  or  execution. 

i)  Learning  objectives 

[=1  Scenarios 

In  this  tutorial,  you  will  create  a  simple  process  model,  learning  howto  start  a  project  and  add  a  variety  of  eleme 

process  diagram.  After  completing  this  tutorial,  you  will  be  able  to: 

•  Use  the  Quickstart  wizard  to  create  a  project 

0  03  Tutorial:  Defining  organizations 

•  Create  and  use  a  process  catalog 

0  03  Tutorial:  Defining  structures 

•  Create  a  business  item  and  associate  it  with  a  connection 

0  03  Tutorial:  Running  simulations 

•  Add  a  task  to  your  process  model 

0  03  Key  concepts 

•  Add  data  labels  to  your  diagram 

0  03  Installing  Business  Integration  Modeler 

•  Add  a  simple  or  multiple-choice  decision  to  your  process  model 

0  03  Migrating  from  4,2.4 

•  Add  a  merge  to  your  process  model 

Figure  1.  Tutorials  in  Business  Modeler  help 


The  five  tutorials  are: 

•  Creating  a  simple  process  model, 

•  Defining  resources, 

•  Defining  organizations, 

•  Defining  structures, 

•  Running  simulations. 


Recommendation  1.  Complete  the  tutorials  before  undertaking  your  first 

project. 


2.1.2  Creating  Workspaces 

Each  workspace  should  contain  only  a  single  project,  and  hence  the  business  processes 
of  a  single  logistics  system.  This  helps  avoid  confusion  when  amending  a  project  and 
facilitates  the  exchange  of  workspace  with  other  users.  Workspaces  can  be  zipped  and 
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shared  with  users  who  can  unzip  a  workspace  and  use  it  straight  away  without 
additional  configuration.  This  approach  is  also  advantageous  when  creating  backups  of 
workspaces,  which  is  described  in  section  2.1.3  later. 


NOTE:  Business  Modeler  does  have  the  capability  to  handle  multiple 
projects  in  a  single  workspace  but  by  using  multiple  workspaces  allows  for 
easy  management  of  activities. 


Recommendation  2.  Workspaces  should  be  used  to  manage  activities. 
Recommendation  3.  Each  workspace  should  contain  only  one  project. 


2.1.3  Backing  up 

The  workspaces  need  to  be  backed  up  every  time  a  significant  change  is  made  to  the 
model.  This  is  because  Business  Modeler  can  occasionally  crash  and  corrupts  open 
workspaces1.  The  process  for  backing  up  is: 

1.  Compress  the  workspace  by  using  Zip  (or  other  compression  program).  Save  the  file 
as  "model_DDMMMYY .  zip"  e.g.  "model_0lJUN05  .  zip".  In  the  event  where  there  are 
two  changes  in  a  single  day,  follow  the  date  with  an  underscore  and  a  numeric  value 
e.g.  "model_01JUN05_01 .  zip". 

2.  Upload  the  file  to  the  archive  location  (eg.  File  Transfer  Protocol  (FTP)  Server, 
Windows  Share,  Microsoft  Sharepoint  or  other  common  file  storage  system). 

Following  this  process  keeps  the  most  current  version  of  the  workspace  available  to  all 
team  members. 


NOTE:  At  the  time  of  writing  the  Concurrent  Versions  System  (CVS) 
function  within  Business  Modeler  was  not  working  and  an  alternate  method 
was  required  and  is  described  above.  Ideally  the  built-in  CVS  capabilities  of 
Ellipse2  would  be  used  to  save  incremental  versions  of  the  models.  It  is 
possible  to  use  a  standard  instance  of  Eclipse  or  an  alternate  CVS  client  to 
upload  and  maintain  a  CVS  repository  of  the  model  as  many  of  model's  files 
are  just  simple  XML  or  text  files,  which  synchronise  well  with  CVS 
repositories.  Please  follow  the  CVS  client's  instructions  to  upload  and 
maintain  the  model  in  the  repository. 


Recommendation  4.  Back  up  the  workspace  every  time  a  significant  change 

is  made  to  the  project. 


1  This  problem  will  most  likely  be  corrected  in  future  versions  of  Business  Modeler. 

2  IBM  Business  Modeler  is  built  upon  the  Eclipse  Platform  and  can  use  the  standard  Eclipse 
functions  like  CVS. 
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2.1.4  Use  Advanced  Mode 

Within  Business  Modeler,  there  are  three  user  modes:  basic,  intermediate  or  advanced 
mode.  For  all  models  developed  under  the  FLIE  task,  advanced  mode  is  recommended 
as  it  allows  the  most  flexibility  when  developing  the  process  model,  and  shows  all 
possible  features  that  basic  and  intermediate  modes  hide.  This  allows  the  greatest 
amount  of  information  to  be  captured  about  the  model,  which  will  allow  quicker 
migration  to  execution  engines  when  implementing  the  completed  models. 


Recommendation  5.  Use  the  'advanced'  mode  when  creating  or  amending  a 

project. 


2.1.5  Annotations 

For  the  final  process  model  release,  annotations  should  be  appended  to  all  elements.  As 
annotations  are  a  nuisance  during  development,  it  is  recommended  that  these  are  only 
added  once  the  process  model  is  complete.  Refer  to  Figure  2  for  an  example  process 
displaying  an  annotation. 


Recommendation  6.  Add  annotations  once  a  majority  of  development  is 

complete. 


* 

►  D 

Task 

\ _ / 


*- 


|  This  is  an  annotation. 


Figure  2.  Example  of  an  annotation 

In  addition  to  annotations,  a  description  can  be  added  to  tasks,  decisions,  or  any  other 
process  element.  It  is  recommended  that  these  descriptions  contain  identical  text  to  that 
of  the  annotation  attached  to  it.  This  is  to  ensure  that  a  consistent  model  is  developed. 
Annotations  are  only  to  be  used  to  display  graphical  additional  information  important 
to  the  reader  of  the  business  flow.  This  is  especially  true  if  the  model  is  to  be  printed  or 
viewed  outside  the  Business  Modeler  application. 


Recommendation  7.  An  element's  description  and  annotation  should  have 

the  same  text. 

Recommendation  8.  Display  annotations  to  enhance  user  understanding 

especially  when  viewed  outside  Business  Modeler. 
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2.1.6  Global  tasks 

Tasks  within  a  process  model  can  be  either  local  or  global.  It  is  good  practice  to  create 
tasks  as  global  when  a  particular  task  needs  to  be  used  over  multiple  process  models.  If 
a  local  task  is  created  instead  of  a  global  one,  that  local  task  is  only  visible  in  the  process 
model  in  which  it  was  created. 


Recommendation  9.  If  a  task  needs  to  be  used  over  multiple  process  models, 

then  that  task  should  be  global.  Avoid  entering  two 
separate  local  task  with  the  same  name. 


Global  tasks  are  listed  under  the 'Process  catalogs  ->  Processes  ->  Tasks' section 
of  the  process  tree.  Catalogs  should  be  created  under  the  "Tasks"  directory,  in  order  to 
group  common  tasks. 


Recommendation  10.  Common  tasks  should  be  grouped  into  catalogs. 


2.1.7  No  White  Space  in  Process  Model  or  Artifact  Names 

When  creating  resources,  business  items  or  other  process  model  artifacts,  it  is 
recommended  that  these  artifacts  do  not  contain  spaces  in  their  name.  This  is 
recommended  because  models  that  are  eventually  converted  into  Business  Process 
Execution  Language  (BPEL)  output  will  not  recognise  items  that  contain  spaces  in  their 
name. 

If  needed,  underscores  ('_')  can  be  used  to  separate  words.  For  FLIE,  spaces  are  to  be 
removed  and  "Camel  Case"  to  be  used3.  For  example,  'Movement  Process'  would  be 
written  as  'MovementProcess'. 


Recommendation  11.  Ensure  process  model  and  artifacts  do  not  have  spaces 

in  their  names. 

Recommendation  12.  FLIE  staff  should  use  "Camel  Case"  formatted  names. 


2.1.8  Display  of  Resources  and  Organisations  in  Process  Models 

In  process  models,  attributes  such  as  a  resource,  can  be  displayed  and  assigned  to 
particular  elements.  It  is  recommended  that  all  Business  Modeler  projects  used  in  FLIE 
should  display  all  organisations  and  resources  within  a  process  model.  Displaying  these 
attributes  in  the  diagram  allows  for  easier  understanding  of  the  concepts  depicted  in  the 
process  model. 

To  enable  the  display  of  these  attributes,  select  the  'visual  attributes'  tab  while  a 
process  model  is  open.  When  the  'visual  Attributes'  screen  is  displayed,  select 
'Labels'  and  set  the  'Top  label'  to  'individual  resource  requirements'  and 


3  "Camel  Case"  is  the  practice  of  capitalising  the  first  letter  of  each  word  and  removing  all  space, 
for  example  the  name  "Gather  External  Data"  would  become  "Gather ExternalData".  This 
approach  is  named  because  of  the  likeness  of  the  capital  letters  to  that  of  the  humps  of  a  camel. 
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'Bottom  label'  to  'Organization  units'  for  'Global  task'.  Refer  to  Figure  3  and 
Figure  4  to  see  example  screenshots  of  the  'visual  Attributes'  screen  and  the  final 
result. 


Labels 

Set  top  and  bottom  labels  for  process  elements 

l~l  Hide  all  labels 


Process  element 

Top  label 

Bottom  lc 

Global  task 

Individual  resource  requirements 

Organiza 

Local  task 
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chide  lat 

Global  service 
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chide  lat 

Local  process 

chide  label  > 

Chide  lat 

Global  process 

chide  label  > 

chide  lat 

Notification  broadcaster 

Chide  label  > 

Chide  lat 

Notification  receiver 

chide  label  > 

chide  lat 

Observer 

chide  label  > 

chide  lat 

Timer 

chide  label  > 

Chide  lat 

Map 

chide  label  > 

chide  lat 

While  loop 

chide  label  > 

Chide  lat 

Do-while  loop 

chide  label  > 

chide  lat 

For  loop 

chide  label  > 

chide  lat 

Local  repository 

chide  label  > 

chide  lat 

Global  repository 

chide  label  > 

chide  lat 

□  Show  label  headings 


Figure  3.  Visual  attributes 


MMS  Application 


Figure  4.  How  resources  and  organisations  appear 


* 

Generate 
N  Summaries  7 

JMOVGP 


Recommendation  13.  All  global  tasks  of  a  process  model  should  display  their 

associated  organisation  and  resource  attributes. 


2.1.9  Local  Processes 

Some  process  models  can  become  quite  large  and  complex.  For  this  reason  creating  local 
processes  is  encouraged  as  a  good  habit  to  develop.  It  is  good  practice  to  group  related 
tasks  that  occur  sequentially  into  a  local  process,  therefore  minimizing  the  display  size 
of  the  parent  model. 


Recommendation  14.  Group  sequential,  related  processes  elements  as  a  local 

process. 
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2.1.10  Structuring  local  processes 

Local  processes  are  used  to  group  related  tasks  into  one  aggregated  task,  thus  reducing 
the  main  process  model's  visible  size.  There  are  multiple  methods  to  structure  local 
processes,  the  method  used  in  FLIE  is  described  below. 

1.  Add  a  Local  Process  element  to  the  process  model. 

2.  Edit  the  Local  Process  by  selecting  the  expand  button  located  inside  the  element 
itself. 

3.  Within  the  Local  Process  a  Start  and  Stop  node  are  automatically  added.  The  Start 
and  Stop  nodes  are  needed  to  construct  a  Local  Process  properly. 

4.  Add  additional  tasks  as  required  to  map  the  Local  Process's  process  flow. 

If  the  Local  Process  needs  to  return  a  business  item,  then  a  business  item  can  be  passed 
to  the  Stop  Node  and  the  business  item  will  appear  as  the  output  of  the  Local  Process.  It 
is  desired  to  pass  the  business  item  to  the  Stop  Node  and  not  the  output  of  the  Local 
Process.  If  passed  to  the  output  of  the  Local  Process,  simulation  of  the  process  model 
will  not  work  properly.  Refer  to  Figure  1  below. 

Note:  there  are  other  ways  to  structure  local  processes,  but  this  method  is  the  preferred 
way. 


Recommendation  15.  Always  have  a  start  and  stop  node  in  a  local  process. 


Figure  5.  Normal  local  process 

2.2  General  Practices 

The  practices  listed  above  were  specific  to  the  work  conducted  under  the  DSTO  FLIE 
task.  The  following  sections  describe  more  general  practices  that  should  be  followed  for 
most  other  projects.  These  practices  relate  mainly  to  how  process  models  are  structured 
and  created. 

2.2.1  Use  of  Merges  and  Joins 

Merges  and  joins  are  two  components  that  combine  multiple  inputs  into  a  single  output, 
but  each  works  in  very  different  ways.  A  merge  waits  until  one  of  the  inputs  arrives, 
and  continues  the  process  using  that  input  (other  inputs  are  ignored).  Joins  however, 
waits  until  all  inputs  have  arrived  before  continuing  along  the  process  path. 

Merges  are  typically  used  in  conjunction  with  decisions,  and  are  used  with  all  decisions 
in  all  our  process  models  for  the  FLIE  task.  This  is  a  similar  construct  to  that  of  a  'switch' 
statement  in  programming  languages,  where  based  on  an  input  a  task  is  run  before 
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continuing  the  program's  normal  procedure.  The  practice  of  structuring  decisions  is 
described  in  section  2.2.3  on  page  9,  which  involves  using  a  merge. 


Recommendation  16.  Merges  should  be  used  to  combine  after  a  decisions 

action  is  completed. 


Joins,  as  the  name  suggests,  waits  until  all  input  has  arrived  and  subsequently  combines 
them  into  one  output.  Problems  will  arise  when  inputs  to  a  join  contain  differing 
business  items  because  an  error  will  be  produced.  A  different  structure  is  needed  to 
work  around  this  and  is  described  in  section  2.2.8  on  page  13. 

2.2.2  Structuring  While  Loops 

There  are  many  approaches  to  structure  a  While  Loop.  As  the  activity  of  adding  While 
Loops  was  not  easily  understood  a  description  of  the  method  employed  is  described 
below  as  used  in  the  FLIE  task. 

To  start  insert  a  While  Loop  in  a  process  model,  and  connect  the  appropriate  elements. 
Expand  the  While  Loop  object  by  selecting  the  expand  button  located  within  the  While 
Loop  graphic.  This  opens  a  local  process  representing  the  internal  loop  logic.  By  default 
a  start  node  is  already  added.  Create  a  stop  node  and  add  all  the  elements  (tasks, 
process  control,  etc.)  required  to  represent  the  While  Loop  logic.  It  is  essential  that  the 
start  and  stop  nodes  are  defined  within  the  While  Loop,  otherwise  simulations  will  fail 
to  execute  properly.  See  Figure  6  below  for  an  example  loop  process  diagram. 


Recommendation  17.  Always  include  a  start  and  stop  node  within  each 

While  Loop. 


Figure  6.  Internal  structure  of  a  while  loop 

The  condition  that  the  While  Loop  check  against  as  to  whether  is  should  continue 
looping  or  stop  is  not  specified  in  the  expanded  While  Loop;  instead  the  condition  is 
defined  in  the  'Loop  Condition'  tab.  This  tab  is  accessed  when  the  While  Loop  is 
selected  on  the  parent  process  diagram.  On  this  tab  an  expression  or  probability  can  be 
defined  (see  Figure  7). 
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iagram  Specification  Key  performance  indicators  Visual  attributes 


General  Inputs  Outputs  Input  logic  Output  logic  Loop  condition  Organizations  Classifiers  Observation  point 


|  Loop  Condition 


hey 


Probability(%) 


every  ('Processes .  while .  file'  true) 


Clear  Expression 


Figure  7.  While  loop  and  loop  condition 


2.2.3  Structuring  Decisions 

Decisions  are  elements  that  Business  Modeler  uses  to  describe  what  programmers 
usually  call  'if  statements'.  Decisions  have  two  outputs;  their  selection  in  a  running 
process  is  decided  by  either  the  evaluation  of  an  expression  or  by  a  probability  assigned 
to  each  output.  Described  below  are  the  steps  used  in  the  FLIE  task  to  create  a  Decision 
flow. 

1.  Insert  a  decision  element  into  the  process  model. 

2.  Specify  the  tasks  to  be  executed  in  accordance  with  the  decision. 

3.  Create  a  merge  element,  and  merge  the  two  outputs  of  the  decision  into  it.  The  merge 
will  wait  until  an  input  arrives  before  continuing  execution. 

4.  The  process  should  look  similar  to  that  shown  in  Figure  8. 


Figure  8.  Structuring  a  decision 
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As  stated  earlier,  either  probabilities  or  expressions  can  be  specified  in  a  Decision. 
Condition  values  are  specified  by  selecting  a  Decision  element  and  clicking  the  'output 
Branches'  tab.  Probabilities  are  a  good  approach  for  decisions  that  randomly  select  a 
path,  as  opposed  to  an  expression  that  defines  the  execution  path  solely  based  on  its 
inputs  and  the  evaluated  expression. 


2.2.4  Using  Broadcasters  &  Receivers 

Broadcasters  and  Receivers  work  in  conjunction  and  are  linked  with  a  Notification. 
When  a  Broadcaster  is  triggered,  the  associated  notification  is  initiated.  This  in  turn 
triggers  any  receivers  waiting  for  that  notification  message.  Process  execution  restarts 
with  all  triggered  Receivers.  Described  below  is  the  procedure  to  use  these  components. 

1.  Create  and  add  a  Broadcaster  and  Receiver  to  the  process  model. 

2.  Create  a  notification  by  right  clicking  'Data  catalogs'  from  the  Project  Tree  and 
select  'New'. 

3.  Drag  the  new  Notification  onto  both  the  Broadcaster  and  Receiver  to  associate  it  with 
each  element.  This  action  creates  the  connection  between  the  Broadcaster  and 
Receiver. 

4.  Now  you  have  a  Broadcaster  that  sends  out  a  Notification  and  a  Receiver  that  is 
initiated  when  it  sees  the  same  Notification. 

After  a  Broadcaster  sends  a  Notification,  if  the  process  no  longer  needs  to  continue  then 
it  is  good  practice  to  connect  the  Broadcaster's  output  to  an  End  Node  (see  Figure  9). 
This  ensures  processing  does  not  continue  beyond  the  Broadcaster  element.  However,  if 
the  process  needs  to  continue  after  the  notification  has  been  sent,  then  simply  connect 
other  elements  to  the  Broadcaster's  output  as  shown  in  Figure  11. 


Recommendation  18. 

If  no  tasks  need  executing  after  a  Broadcaster  has  sent 
its  Notification  then  connect  an  end  node  to  the 

Broadcaster's  output. 

Once  a  Receiver  catches  a  Notification  the  process  is  once  again  continued  from  the 
Receiver  element  as  shown  in  Figure  10. 


Notification 

Broadcaster 


Figure  9.  Broadcaster  with  end  node 
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Figure  10.  Receiver  continues  the  sequence  of  execution 


-  < 


Figure  11.  Task  performed  after  broadcaster 


2.2.5  Creating  Resources,  Business  Items  and  Artifacts 

The  creation  of  artifacts  in  a  project  is  accomplished  in  many  ways  with  varying 
complexity  and  detail.  In  FLIE  tasks,  the  level  of  detail  required  is  quite  high  in  order  to 
enable  accurate  simulations.  The  creation  of  a  Business  Item  will  be  used  as  an  example 
to  illustrate  the  level  of  detail  required. 

1.  Once  a  Business  Item  has  been  created,  double  click  it  from  within  the  'Project 
Tree'  to  display  its  attributes. 

2.  If  required  select  a  parent  template,  otherwise  proceed  to  add  attributes  to  the 
business  item.  Each  Business  Item  should  be  as  detailed  as  possible.  For  example 
descriptions,  cardinality,  uniqueness  should  be  added  as  an  absolute  minimum.  The 
example  shown  in  Figure  12  contains  a  business  item  named  'order'  with  the 
attributes  'id',  'name',  'seller',  'date'  and  'items'  added  to  it. 


Parent  template  |  None 


m 


Change  Icon 


Business  item  attributes 

Attributes  are  editable  fields  that  characterize  this  business  item. 


Selected  attribute  details 

Details  of  the  selected  attribute,  including  comment  and  governing 
rule. 
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Attribute  description 

This  is  the  unique  identity  number  for  an  order 


31 


PI  Has  rule 

Attribute  rule  name 

|  Rule  | 

Attribute  rule  description 

~ 3 

A 

Expression 

'Business  items. File. id'  is  less  than  or  equal  to  100.0 

1 

Clear  Expression  Edit  Expression  I 
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Figure  12.  Details  for  order 
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Rules  can  also  be  applied  to  attributes.  To  add  rules,  select  an  attribute  and  select  the 
'Has  Rule'  checkbox.  Enter  a  'name',  'description'  and  'expression'  for  the  attribute. 


Recommendation  19.  Add  as  much  detail  as  possible  to  all  elements. 


2.2.6  Using  end  nodes 

An  End  Node  indicates  to  Business  Modeler  that  a  process  execution  must  stop  at  that 
particular  point.  While  this  is  not  strictly  necessary,  it  does  provide  a  visual  guideline  to 
the  Business  Modeler  user.  Figure  13  shows  an  end  node  used  within  a  decision 
construct.  This  process  contains  the  logic  that  if  a  customer  is  18,  then  the  order  will 
proceed  and  the  sequence  of  execution  will  finish  (at  the  stop  node),  otherwise  the 
process  will  end  (at  the  end  node).  Figure  9  (on  page  10)  shows  another  example,  where 
a  broadcaster  sends  a  notification  and  execution  ends  immediately  after  sending  the 
notification. 

Do  not  get  confused  between  End  Nodes  and  Stop  Nodes.  End  nodes  will  halt  the 
process  flow  at  that  particular  point,  but  other  currently  executing  flows  will  continue  to 
work.  Stop  nodes  halt  the  whole  process  altogether,  and  any  other  currently  executing 
flows  will  stop  as  well. 


ifl  J  start  node 


[flj  stop  node 

'<§> 


50.0%  No 


fflj  end  node 


Figure  13.  End  node  in  a  decision 


Recommendation  20.  Always  put  an  end  node  in  a  sequence  where  execution 

ends. 


2.2.7  Structuring  Concurrent  Processes 

Concurrent  processes  occur  when  a  single  input  gets  split  into  multiple  outputs,  and 
those  outputs  are  concurrently  processed  by  different  Activities  (see  Figure  14).  These 
concurrent  processes  can  continue  until  the  process  finishes,  or  join  back  together  as 
shown  in  Figure  14  below. 
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Figure  14.  Concurrent  processing  example 


The  example  above  represents  the  process  of  purchasing  a  meal  at  a  fast  food  restaurant. 
Once  an  order  is  placed,  the  employee  at  the  check  out  will  set  up  the  drink  to  be 
automatically  poured,  meanwhile  another  employee  collects  the  remainder  of  the  meal 
and  places  it  on  a  tray.  Only  when  both  the  drink  and  food  are  on  the  tray  does  the 
process  continue  and  the  customer  pays  for  their  food.  This  example  uses  a  fork  to  start 
the  concurrent  processes  and  then  a  join  to  return  to  a  single  process  path. 


Recommendation  21.  Use  forks  and  joins  to  model  concurrent  processes. 


2.2.8  Structuring  Concurrent  Processes  with  Business  Items 

There  may  be  situations  where  multiple  outputs  need  to  join  back  into  a  single  output, 
but  one  of  those  outputs  contains  differing  business  items,  which  means  that  it  cannot  be 
used  as  a  single  input.  If  the  conventional  method  of  joining  multiple  inputs  is  followed 
(see  section  2.2.7  on  page  12),  errors  will  occur  because  a  Join  element  joins  all  outputs 
together,  and  Business  Modeler  is  expecting  these  to  be  of  the  same  type.  The  solution 
for  this  scenario  is  described  below. 

Create  a  similar  process  model  to  that  in  section  2.2.7  (see  Figure  14),  except  that  for  any 
output  that  passes  a  business  item,  a  second  output  needs  to  be  created  to  pass  the 
Business  Item  onto  the  task  after  the  Join.  For  example  in  Figure  15  only  'Task: 2' 
outputs  a  Business  Item  but  this  output  is  different  to  that  of  'Task'  just  above,  and 
therefore  if  their  outputs  were  simply  joined  then  an  error  would  occur.  To  overcome 
this  an  additional  output  is  created  on  'Task: 2'  and  connected  to  the  Join,  while  the 
Business  Item  output  is  connected  to  'Task :  3'.  This  results  in  a  process  that  processes 
'Task'  and  'Task: 2'  concurrently,  waits  for  both  to  complete  with  the  Join  and  then 
executes  'Task :  3'  using  the  business  item  from  'Task :  2'  and  the  standard  output  from 
the  join. 


\ _ / 


Figure  15.  Workaround  when  business  items  are  involved 

This  solution  is  a  workaround  to  enable  the  simulation  to  work  and  is  required  due  to 
the  processing  nature  of  Joins.  These  types  of  additional  processing  structures  are 
required  as  process  models  in  Business  Modeler  can  actually  be  exported  and  executed 
live  against  real  systems,  unlike  many  other  process  modeling  tools  where  the  output  is 
simply  a  pretty  diagram. 
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2.2.9  Expressions 

Expressions  can  be  added  to  some  process  model  elements,  such  as  Decisions,  While 
Loops  and  Observers.  These  elements  evaluate  expressions  during  simulations  to 
determine  what  outcome  should  occur.  It  is  strongly  encouraged  that  expressions  be 
assigned  wherever  possible  as  this  enables  process  simulations  and  thus  furthers 
understanding  of  what  is  supposed  to  occur  during  process  execution.  It  should  also  be 
noted  that  expressions  can  only  be  created  using  Business  Modeler's  Expression  Builder 
and  not  by  manual  keyboard  input. 


Recommendation  22.  Assign  expressions  to  decisions,  while  loops  and 

observers  wherever  possible. 


2.2.10  Running  Process  Simulations 

A  Process  Simulation  is  a  simulation  of  a  process  model.  This  simulation  allows  users  to 
view  how  the  process  performs  and  responds  to  varying  inputs  into  the  process..  The 
results  of  a  process  simulation  details  information  regarding  time  durations,  costs  and 
resource  usage. 

It  is  possible  to  dynamically  change  attribute  values  of  Business  Items  at  task  output 
during  simulation  execution.  These  dynamic  changes  can  alter  the  sequence  of  events  in 
the  model  and  return  alternate  results  allowing  for  the  testing  of  different  scenarios.  To 
make  these  dynamic  changes  follow  these  steps: 

1.  Start  by  taking  a  Simulation  Snapshot. 

2.  Next  select  a  task  that  outputs  a  business  item  and  select  the  'Business  item 
creation'  tab. 

3.  Select  the  appropriate  output  and  click  the 'Create  simulation  values' button. 

4.  From  this  new  screen  it  is  possible  to  change  the  Business  Item's  values  to  be  output 
after  the  task  selected  in  step  2  above  has  completed. 
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These  practices  and  recommendations  have  been  produced  to  help  future  IBM  Business 
Integration  Modeler  Advanced  Edition  users  overcome  some  of  the  problems 
encountered  by  the  FLIE  team.  More  importantly  this  document  has  been  produced  so 
that  future  FLIE  task  members  do  not  have  to  relearn  these  lessons.  The  practices  and 
recommendations  documented  herein  arein  no  way  complete  and  this  document  should 
be  read  in  conjunction  with  the  IBM  Quickstart  Guide  and  tutorials  to  gain  a  complete 
appreciation  of  the  product.  It  is  expected  that  over  time  as  FLIE  task  members  use  this 
software  additional  practices  will  be  developed;  therefore,  for  the  latest  version  please 
refer  to  the  DSTO  FLIE  Sharepoint  task  page[4].  If  you  have  any  comments  or  additional 
recommendations,  best  practices  and  patterns  in  the  use  of  Business  Modeler  please 
contact  Egon  Kuster  (FLIE  task  manager.  Command  and  Control  Division,  DSTO). 
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